Shape Up - Chapter 1: Introduction
Shape Up - Chapter 1: Introduction
Growing Pains: 成長痛
葛藤
チームメンバーはプロジェクトが終わりが見えないまま永遠と続いているように感じる
プロダクトマネージャーは製品について戦略的に考える時間が見つからない
どうして最初みたいにうまくいってないんだろう?
4人 -> 50人以上に成長したBasecampでも発生した
最初のBasecamp
Jason Friedが設計
DHHがプログラミング
Ryan SingerがUIデザイン
2003/07 ~ 2004/02まで、DHHは10h/weekしか働いていなかった
スコープを "hammering - 打ち込む" ことに集中することになった
2015
コアチームと共にとても成長できたが、新入社員に何をしているのかを伝えるのがすごく難しかった
プロダクトチームは4倍になった。全員リモートだった。何をしているのかを伝えるための「言語」と「構造」が必要だった
アドホックなプロジェクト型から、サイクルを繰り返すようになった。(長さは結構実験した)
"pitching" と "betting" のプロセスを作った。
何? mactkg.icon
Ryanは、チームが着手する前に前もって行うデザイン仕事を表現する方法を考えてて、"Shaping"とした。
スコープを決めたり(boundaries)、プロジェクトのリスクを減らしたり
Shape Upは2つのトピックを扱ってる。
1: プロダクト開発中に必ず出てくるリスクや不確実性、チャレンジとうまく対処するための言語を提供する
2: Basecampの今の規模で実際どんなプロセスを使って仕事しているか
Six-week cycles: 6週間のサイクル
6週間で仕事をしている。この時間は何か意味のあるものを作りきるのにちょうどいい
6wって1~1.5mmって感じか。
basecampは6週間のサイクルでだいたいリリースされる
全ての決定は6週間でプロダクトを前進させるという考えに基づいていて、時間をマイクロマネジメントするということは考えていない
時間は数えない。それぞれどう過ごしたかなんてどうでもいい。「これが6週間後出荷されたら幸せになる。自分の時間をいい感じに使えたと感じられるはず。」ということだけを自分に言い続ける。あとはチームを1人にして、やるだけ
Shaping the work
チームを作る前に仕事を形にしていく。
小さいシニアグループがサイクルチームと並行して作業する。
ソリューションのKey Elementsを定義して、プロジェクトの準備ができているか考える
Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.
プロジェクトは適度な抽象度で定義される。チームが何をすればいいのかわかる程度に十分に具体的だけど、面白いところは自分たちで取り組めるくらいの余白は残す。
いうは易しだなw mactkg.icon
Shapingするときは、見積もりを重視するのではなく、興味とか欲求(appetite)を重視する
「どれくらいかかる?」ではなくて「どれくらい使いたい?」「どれくらいの価値があるのか?」これがShaping
課題を掘り下げ、欲求の制約の中に収まる解決策の輪郭をデザインする
Making teams responsible: チームが責任を持つ
全ての責任をデザイナーとプログラマが持つ小さい統合チームに委ねている。
自分でタスクを定義して、スコープを調整して、垂直方向に機能を作っていく。
メリット
チームが自律的 - autonomousになれば、シニアメンバーはチームの管理をしなくてよくなる
シニアメンバーは良いプロジェクトをどんどん作っていける
プロジェクトがうまくshaped されていれば、境界がわかりやすくなり、もっと自律的になる
Targeting risk: リスクに狙いを定める
全てのプロセスで納期通り出荷できないリスクを扱いたい
間違ったものを作るリスクは紹介しない
探索(discovery)プロセスの改善はまず作れる(デリバリーできる)ようになってからやりゃいい
世界最高の戦略を持っていてもそれを実行できなくては意味がない
この本で扱うリスクの例
スタックしてしまうリスク
前クオーターの仕事の泥沼にはまってしまうリスク
何これ?
get bogged down
で泥沼にはまる
想定外の問題に時間を費やしてしまうリスク
明日やりたいことが自由にできないリスク
プロジェクトをタイムボックスに入れる前に、いくつかのオープンな質問を解決しておくことで、"Shaping"プロセスのリスクを低減できる。
6週間は「サーキットブレーカー」になっていて、これ以上延長しない。
早めにデザインプロセスとプログラミングプロセスを統合することで、リスクを減らす。
この本の作り
Part1: "Shaping"
スケジュールする準備ができていると考える前に、何をするか。
アイディアの設定
解決策のスケッチ
潜在的なプロジェクトを提示するピッチの作成
breadboarding, fat-marker-sketching
prototypingの手法だな mactkg.icon
Part2: "Betting"
提示されたプロジェクトの中からどう選択して、6週間かけて何をするか
Shapingは誰がやるんだろ、やらないってなったらどうなるんだろう
Part3: "Build"
チームへの期待と、何をすべきかを見つけるためのプラクティス
チームがどうやって何をすべきかを把握して、デザインとプログラミングを統合して、知っていることと知らないことを追跡するか
最終的に、プロジェクトを期限内に完了させるためにどうやって困難な決断を下すのか
Appendix
自分の会社で調整する方法
6週間の実験を試す方法
自分の規模に調整するヒント
Basecampを使ってやるにはどうしたらいいか?w